Software applications that are intended to be run without an operating system (OS) are often referred to as ‘bareboard systems’. In the Executable and Linkable Format (ELF) common standard file format, first published in the System V Application Binary Interface specification (System V being a version of the UNIX™ operating system originally developed by AT&T™, and later in the Tool Interface Standard, the object file type (e_type) for such applications is “executable file”, as opposed to, for example, “relocatable file” or “shared object file”. Accordingly, within the ELF standard, such applications cannot use shared object files, such as shared libraries, or independent relocatable files (e.g. relocatable modules loaded by an operating system).
A problem with such applications is in the enabling of a debugger to correctly identify a current debugging context for the application, for example source mapping, variables view, breakpoint location, etc. In particular, without the ability for the debugger to correctly identify a current context, it is not possible to accurately detect the source information for code that is relocated.
Applications that comprise bareboard systems can be divided into two types: those that have context switches when the application is run, and those that do not. A context switch may be considered to take place, for example, when a section of memory (in a form of a code or data) is relocated, e.g. when a section of code is copied, or ‘mapped’ into program (physical) memory and becomes ‘active’, and the execution of the application continues from the new location where the code was copied in memory. Additionally, a context switch may be considered to take place when a Memory Management Unit (MMU) configuration is changed. For example, an MMU configuration change may take place when any information regarding the MMU, for example such as information held in the Translation Lookaside Buffer (TLB), MMU registers, etc., (depending on MMU design) is updated.
In the case of bareboard system applications that do not have context switches when the application runs, debugger information generated by the compiler is typically sufficient to identify a current debugging context, since there is no change of context during the application. Accordingly, all memory spaces are visible throughout the running of the application, and therefore hardware and software breakpoints are always valid.
In the case of bareboard system applications that have context switches when the application runs, since such applications run without an operating system, the applications themselves act as small operating systems in order to perform the context switches. For some applications, the compiler/linker therefor may generate debugger information for some context switches (overlay support). With such overlay support, the compiler/linker (sometimes referred to as an overlay manager) generates debugger information when the code and data are copied into program memory, thereby allowing the application to be compiled without position independent code and data. For example, the overlay manager may define variables for supporting overlay debugging, such as an overlay mapped address, an overlay load address, the size of the overlay, a flag indicating whether the overlay is currently mapped, etc. Such overlay support enables context switches resulting from different overlay sections of code/data being loaded into program memory to be identified by a debugger. Furthermore, the overlay manager may define a function that, if called, enables a debugger to set a breakpoint at that point. In this manner, the overlay manager may cause this function to be called whenever the overlay table is changed, enabling the debugger to keep track of those overlays that are currently mapped into program (physical) memory, and update any breakpoints that may be set accordingly.
Whilst an overlay manager may provide information relating to context switches resulting from the use of overlays, it does not provide information relating to context switches resulting from MMU configuration changes. In addition, such overlay support is not always available or appropriate. For example when an overlay section is relocated to two different memory locations, that overlay section will require two different overlay mapped address values, which cannot be supported by an ‘overlay mechanism’, per se. Furthermore, an overlay table (e.g. the_GNU ovly_table variable) may not be placed in read-only memory, because the overlay manager requests an update of this table whilst the application is running. Without such overlay support being provided by the overlay manager, the application is required to be compiled with position independent code and data, since the compiler/linker only generates debugger information for the original location code and data. The use of such position-independent code and data means that the debugger is unable to identify a current context without additional information.
Typically, in order to enable a debugger to correctly identify a current context for such an application comprising context switching, where overlay support is not available, a user is required to manually set the correct debug context for each MMU configuration change and code relocation. This approach is very difficult because the user (debugger) needs to know the specifics of the code she/he is debugging, and typically the user (debugger) is not one of the architect engineers that is responsible for writing the application being debugged.
Furthermore, since the number of hardware breakpoints that can be set at any one point is limited (depending on the specific hardware implementation), event points that make use of hardware breakpoints should not be set for an area of RAM (Random Access Memory) when that area of RAM has not been initialised and the relevant application code has not been relocated yet, and such breakpoints should be removed when the context becomes invalid.